In the field of performance testing for data-packet-networks (DPNs), administrators attempt to gauge performance characteristics of various network segments and lines in real time in order to better manage network traffic. In most applications there are four basic measurements whose results provide various pieces of information regarding some aspect of performance. These four basic measurements are:                Latency-defined as the average time it takes a data packet to travel from one point on a DPN to another point on the DPN.        Jitter-defined as variation in latency measured between two endpointson a DPN over a given time frame.        Packet Loss-defined as a percentage of data packets that become lost between two points of a DPN.        Throughput-defined as a maximum value of number of bits per second that are transmitted between two points on a DPN segment in both directions.        
The above-described values can change or evolve over time for any specific line or segment of a network that is used as a routing path between two test points. Therefore, testing is routinely performed on a periodic or, in some instances, on an ongoing basis.
In prior art, performance measurement of a DPN segment is traditionally practiced by injecting data signal packets onto the segment from a node configured as an end node at one end of the segment to be tested. The destination of the injected signal packet is another node at the other end of the segment to be measured. Each test signal is provided a time stamp before send and each signal is captured at the other end node. Latency for each send/receive is calculated for each signal packet at the target-receiving node on the segment by comparing the timestamp provided to the signal packet with the current time the packet was received and logging the time difference for each packet received. In this case, the receiving node must carry the same time reference clock as the sending node, or at least, know by reference the receiving nodes time zone. Latency for data sent in one direction from one sending node to one receiving node on the segment can be calculated by averaging the time differences noted over multiple instances of the signal packet sent and received.
Latency is more accurately measured in one direction. Either direction of the bi-directional segment may be tested with the receiving node performing the calculations for a particular test flow. Another less accurate method involves sending a time-stamped echo packet and then waiting for a response acknowledgement from a target node. To derive the average latency for each direction for a particular transaction, the sending node, after receiving the response packet derives the total time from the time stamp and the current time and divides the time delay by two to give average bi-directional latency.
Jitter is typically derived from ongoing latency calculations as defined above. The number of packets actually received at the target node over a specified period of time is compared with the number of actual packet transmissions from the sending node to derive packet loss ratio. Data throughput is derived from the latency values in both directions.
A drawback to the above-described technique is that data must be injected into the segment bandwidth that is used by the public, possibly reducing available bandwidth that individuals communicating over the segment being tested share. Moreover, testing for latency in one direction requires both end nodes to correctly reference the local time of the sending node for comparing time stamp data.
Another problem may occur over network segments that are enhanced for multiprotocol label switching (MPLS), an Internet Engineering Task Force (IETF) initiative that provides alternate routing paths. In this case the injected signal packets must be sent from the same subnet with reference to source and destination addresses, as are the data packets of a particular customer's data stream that we are trying to emulate. Likewise the injected packets must be serviced according to the same priority. Otherwise, the test can not be sure that it is reporting the conditions that a customer is experiencing because the signal data packets may not travel the same paths or be queued in the same router queues as the customer stream.
With the use of MPLS and other dynamic routing methods then, it is virtually impossible to predict the route of a packet through the network and any injected packet is unlikely to follow the same route in a complex load balanced network.
Therefore, what is clearly needed is a method and apparatus for testing performance of network segments that would solve the problems stated above.